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REMARKS 



Upon entry of the present amendment, claims 1 to 7 will have been amended, claims 8 to 
39 will have been newly added and claims 1 to 39 will be pending. Claims 1 to 7 have been 
amended herein to more clearly recite the invention. Claims 8 to 39 have been added to provide 
an additional scope of coverage. No new matter has been added. 

To aid in the examination of the present application, submitted concurrently is a 
Transmittal Letter to the Official Draftsmen including Replacement Drawings for Figures 1, 2, 
2A-2C, 3-38, 38A, 39-46, 46A, 47, 48, 48A, 48B and 49-63, replacing Figs. 1-63 with formal 
drawings. In this regard, Applicants have endeavored to aid in the clarity of the Drawings and 
their enumeration. 



Attached hereto is a marked-up version of the changes made to the specification and 
claims by the current preliminary amendment. The attached page is captioned "Version with 
markings to show changes made." 



CONCLUSION 
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Favorable consideration and passage to issue of the application at the Examiner's earliest 
convenience are earnestly solicited. 



WOODCOCK WASHBURN KURTZ 
MACKIEW1CZ & NORRIS LLP 
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Version With Markings To Show Changes Made 



IN THE SPECIFICATION: 

Please enter the following amendments to the specification: 

Amend the paragraph beginning on page 1, line 5, as follows: 

-This application is related to U.S. Patent Application No. 60/1 18,668, entitled 
"COMMON DISTRIBUTED OBJECT PLATFORM," filed on February 3, 1999; U.S. Patent 

Application No. 09/322.455 [ ], entitled "METHOD AND SYSTEM FOR 

TRACKING SOFTWARE COMPONENTS," filed on May 28, 1999 [(Attorney Docket No. 

30581.8002.1001)]; U.S. Patent Application No. 09/322.962 [ ], entitled "METHOD AND 

SYSTEM FOR TRACKING CLIENTS," filed on May 28, 1999 [(Attorney Docket No. 
30581.8003.1001)]; U.S. Patent Application No. 09/322.643 [___], entitled "AUDIO 
VISUAL ARCHITECTURE," filed on May 28, 1999 [(Attorney Docket No. 30581.8004.1001)]; 
U.S. Patent Application No. 09/322.459 [ 1 , entitled "METHOD AND SYSTEM 

FOR CONTROLLING ENVIRONMENTAL CONDITIONS," filed on May 28, 1999 [(Attorney 

Docket No. 30581 .8005.1001)]; U.S. Patent Application No. 09/322.207 [ ], entitled 

"METHOD AND SYSTEM FOR DISTRIBUTING ART," filed on May 28, 1999 [(Attorney 

Docket No. 30581 .8006.1001)]; U.S. Patent Application No. 09/322.964 [ ], entitled 

"METHOD AND SYSTEM FOR GENERATING A USER INTERFACE FOR DISTRIBUTED 
DEVICES," filed on May 28, 1999 [(Attorney Docket No. 30581.8008.1001); U.S. Patent 

Application No. 09/322.852 , entitled "METHOD AND SYSTEM FOR MANAGING 

SOFTWARE COMPONENTS," filed on May 28, 1999 (Attorney Docket No. 

30581.8009.1001)]; and U.S. Patent Application No. 09/322.457 [ ], entitled 

"METHOD AND SYSTEM FOR PROPERTY NOTIFICATION " filed on May 28, 1999 
[(Attorney Docket No. 30581.8010.1001)], the disclosures ofwhich are incorporated herein by 
reference.-- 

Amend the paragraph beginning at line 13 of page 2, as follows: 

—Such large distributed systems need to ensure that they can function even when portions 
of the system fail or go off-line for maintenance. For example, when one object goes down 
because of a failure of one computer, the objects that reference that failed object should not also 
fail. In addition, when the failed object eventually comes up, the objects that reference that failed 
object should be able to continue to access the object. This tracking of objects as they go down 
and come up can be very complex. For example, in a large distributed system, there may be no 
guarantee that messages relating to when an object comes up or goes down are received in the 
order in which they are generated or even [event] received at all. Thus, applications accessing 
the objects need to perform these complex processes to ensure that references are current. 
Current object models, however, provide very little support for tracking objects in such complex 
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systems.— 



Amend the paragraph beginning at line 13 of page 15, as follows: 

-The watching of a resource is coordinated by the bus manager, but the monitoring of a 
resource is performed on a client-to-server node basis without interaction from the bus manager. 
When a client wants to watch a resource so that it knows when the resource is in the up state, the 
client node notifies the bus manager. The resource is identified using a tracking reference. If the 
resource is already up, [then] the bus manager then notifies the client node that the resource is up. 
Otherwise, the bus manager notifies the client node when the resource comes up. When the 
client node is notified that the resource is up, it may notify the bus manager to stop watching for 
the resource. The monitoring of a resource is performed on a peer-to-peer basis. That is, once a 
client node is informed that a [an] resource has entered the up state, it establishes a connection 
directly with the server node that contains the resource. Once the connection is established, the 
client node notifies the server node periodically that it is still up and running. If the server node 
does not receive this notification, it assumes that the client node is no longer up and running and 
resets its internal state accordingly. Similarly, if the client node receives an error when sending 
its periodic notification to the server node, it assumes the server node is down and resets its 
internal state accordingly. When the resource goes down, the server node notifies the client node 
that the resource is now down. Each node includes clients 205, a resource tracking system 206, 
and a resource manager 207. A client requests the resource tracking system to provide pointers 
to resources and to notify the client when resources come up or go down. The resource tracking 
system interacts with the resource manager to watch, monitor, and retrieve pointers to the 
resource. The resource manager also detects when resources on its node come up and go down 
and notifies [notify] the bus manager or other nodes as appropriate. The nodes may all be 
computer systems with a central processing unit, memory, and input/output devices. The 
software components and data structures of these nodes may be stored on computer-readable 
medium such as memory, CD-ROM, flexible disk, hard disk, and so on and may be transmitted 
via a data transmission medium.— 

Amend the paragraph beginning at line 1 of page 17, as follows: 

—Figure 2B is a block diagram illustrating the watching of a resource. The client node 
2B10 is a node on which a client 2B1 1 has requested to watch for a certain resource to come up. 
The client node tracks the resource with components 2B12 of the resource manager. The 
resource manager includes a watched resource table 2B13, a process/resource list 2B14, and 
resource directory 2B15. The client and the resource manager interact as described in Figure 2 A. 
The resource manager interacts with a bus manager 2B20 to notify the bus manager when 
resources of that node go up and come down and to request that the bus manager watch for a 
resource on the client node's behalf. The bus manager includes a bus manager component 2B21 
that has a watched resource table 2B22 and a resource directory 2B23. The watched resource 
table at the client node contains an indication of each resource that a client located at that node 
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has requested to watch along with an indication of the requesting client. The resource directory 
at the client node contains the identification of each resource that is currently up at the client 
node. The resource manager uses the resource directory to re-notify the bus manager of the 
resources that are up in the event that the bus manager goes down and then comes back up or 
when another bus manager takes control of the bus. The resource manager similarly uses the 
watched resource table to re-notify the bus manager of the resources that its clients are watching. 
The process/resource list identifies each resource by the process in which it is executing. When 
a process goes down, the resource manager can use the process/resource list to notify the bus 
manager that those resources are now down. The client node sends to the bus manager an attach 
resource message whenever a resource comes up and a detach resource message whenever a 
resource goes down. The client node sends a watch resource message to the bus manager to 
notify the bus manager to start watching for a particular resource to come up. The client node 
keeps track of the resources that itjs [its] watching in the watched resource table. If a client 
requests to watch a resource that another client on the same node is already watching, then the 
client node does not need to send another watch resource message to the bus manager. The client 
node sends a stop watching resource message to the bus manager whenever it wants to stop 
watching for a resource to come up. The client node may want to stop watching for a resource 
whenever all of its clients who were watching the resource request to stop watching the resource 
or whenever the resource comes up. The client node sends a find resource message to the bus 
manager when it wants to retrieve a pointer to a resource. When a client comes up, the bus 
manager sends a watched resource is up message to each client node that is watching that 
resource. The watched resource table of the bus manager contains an identifier of each resource 
that is being watched and the client node that requested a watch of that resource. The resource 
directory of the bus manager contains an identifier of and a pointer to each resource that is 
currently up. When the bus manager receives an attach resource message, it updates the resource 
directory to indicate that the resource is up. It then checks the watched resource table to 
determine whether any client nodes are watching that resource. If so, the bus manager sends a 
watched resource is up message to each such client node. When the bus manager receives a 
detach resource message, it updates its resource directory to indicate that the resource is now 
down. When the bus manager receives a node is down message, it effectively detaches all 
resources that were attached at the node that is now down and effectively stops all the watches 
from that node.-- 

Amend the paragraph beginning at line 2 of page 20, as follows: 

-Figure 3 is a block diagram illustrating data structures of the resource tracking system. 
The resource tracking system provides a directory object 301, a list of resource reference objects 
302, and, for each resource reference object, a list of client objects 303. The directory object 
provides functions for controlling the access to resources by interacting with an installable 
resource manager. The directory object maintains a resource reference object for each resource 
that a client has registered to track. Each resource reference object contains the name of the 
resource and, if the resource is up, a unique instance identifier of the resource (e.g., a pointer to 
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the resource and the time at which the resource was created). Each resource reference object also 
contains a pointer to a client list of client objects that each represent a client that has registered to 
track the corresponding resource. Whenever a client wants to reference to a resource, it supplies 
a client object to the resource tracking system. This client object includes functions that the 
resource tracking system uses to notify the client when the resource changes its state (e.g., a 
call-back routine). Since these data structures may be accessed concurrently by multiple threads 
of execution, a concurrency management technique is used when accessing these data structures. 
For example, before accessing a data structure [structures], a thread may lock the data structure 
and then unlock it after the access is complete. In the following, the description of the functions 
that access these data structures omit these well-known concurrency management techniques.— 

Amend Table 1 beginning at line 10 of page 21, as follows: 



Table 1 
Directory Object 



Name 


Description 


myResRefList 


A pointer to the resource reference list for this directory object 

* . _ — tL aL 


addNewResClient 


A function that is invoked by a client to register that it wants to track a resource. 


ResIsUp 


A function that is invoked by the resource manager to notify the resource tracking 
system that a resource is up. 


ResIsDown 


A function that is invoked by the resource manager to notify the resource tracking 
system that a resource is down. 


busStateChanged 


A function that is invoked by the resource manager to notify the resource tracking 
system that the bus has changed state (i.e., came up or gone down). 


reevaluateRefs 


A function that is invoked by the resource manager to notify the resource tracking 
system to reset all its references [reference] to the down state. 


clearlnitialBlock 


A function that is invoked by the resource manager to notify the resource tracking 
system to start processing notifications. 


GoingAway 


A function that is invoked by a resource reference object to notify the directory object 
that a resource reference object is going away. 


MonitorRes 


A function that is implemented by the resource manager and invoked by the resource 
tracking system to notify the resource manager to start monitoring a resource to go 
down. This function may be provided as a derivation of the directory object. 


stopMonitoringRes 


A function that is implemented by the resource manager and invoked by the resource 
tracking system to notify the resource manager to stop monitoring a resource to go down. 
This function may be provided as a derivation of the directory object. 


WatchRes 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to notify the resource manager to start watching for a 
resource to come up. This function may be provided as a derivation of the directory 
object. 
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stopWatchingRes 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to notify the resource manager to stop watching for a 
resource to come up. This function may be provided as a derivation of the 
directory object. 


Finders 


A function that is implemented by the resource manager and invoked by the 
resource tracking system to retrieve a pointer to a resource. This function may be 
provided as a derivation of the directory object. 



Amend the paragraph beginning at line 2 of page 23, as follows: 



--A pointer used may be "smart pointer" such that when a pointer is copied it is 
automatically reference counted; [,] when the pointer is reset A [to a new] it is automatically 
released. When a smart pointer goes out of scope, its destructor releases it. The myResPtr of the 
resource reference object and myRefResPtr of the client object are smart pointers.-- 

Amend the paragraph beginning at line 5 of page 26, as follows: 

-Figures 14-19 are flow diagrams illustrating the functions of the directory objects. 
Figure 14 is a flow diagram of an example implementation of the Directory: :addNewResClient 
function. This function adds a new client object for a resource to the directory. This function is 
passed the name of the resource (resName) and the client object. In step 1401, the function finds 
the resource reference object associated with the passed resource name by invoking the 
fmdRefRes function of the directory object. That function searches the resource reference list 
and returns a reference to a resource reference object with that name. In step 1402, if a resource 
reference object with that name is found, then the function continues that step 1407, else the 
function continues at step 1403. In steps 1403-1406, the 'function adds a resource reference 
object for the named resource to the resource reference list. In step 1403, the function creates a 
resource reference object. In step 1404, the function adds the resource reference object to the 
resource reference list of this directory object. In step 1405, the function adds the client object to 
the client list of the resource reference object by invoking the add function of the resource 
reference object passing the client object. In step 1406, the function signals the clients that the. 
resource is up by invoking the up function of the resource reference object. If the resource is not 
actually up, the resource tracking system will enter the watch for resource state for this resource 
and notify clients that the resource is down. In step 1407, the function adds the client object to 
the client list of the resource reference object by invoking the add function of the resource 
reference object. In step 1408, the function initializes the client object by invoking the init 
function of the resource reference object passing the client object and then returns.-- 

Amend the paragraph beginning at line 1 1 of page 35, as follows: 

-Figure 31-34 are flow diagrams illustrating the processing of the functions of the client 
object. Figure 31 is a flow diagram of an example implementation of the Client: :resIsUp 
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function. This function is invoked when the resource comes up. In step 3 101, the function sets 
the interface pointer of this client object to null. In step 3102, the function retrieves a reference 
counted pointer to the resource by invoking the getRefCountedPtr function of the resource 
reference object and saves it in a smart pointer. In step 3103, if the client object has an interface 
identifier specified, then the function continues at step 3104, else the function continues at step 
3105. In step 3104, the requested interface pointer is retrieved from the subject resource. In step 
3 105, the function retrieves a pointer to the interface by invoking the query interface function of 
the resource. In step 3105, the function notifies the client derivation that the resource is now up 
by invoking the resourcelsUp function provided by the client. The function then returns.— 

Amend the paragraph beginning at line 1 of page 36, as follows: 

-Figure 33 is a flow diagram of an example implementation of the Client: :deleteYourself 
function. This function is invoked when this client object is to be deleted. In step 3301, the 
function clears the interface identifier of this client object. In step 3302, if this client object has a 
reference to a resource reference object, then the function continues at step 3303, else the 
function continues at step 3308. In step 3303, the function notifies the resource reference object 
that this client is going away by invoking the to be goingAway function. In step 3304, if the 
invocation is successful, then the function continues at step 3305, else the function continues at 
step 3306. In step 3305, the function decrements the reference count for [in] the resource 
reference object and sets its pointer to null. In step 3306, the function sets the delete flag of this 
client object to true. In the step 3307, if this client object has a reference to a resource reference 
object, then the function returns, else the function continues at step 3308. In step 3308, the 
function destructs this client object and returns. -- 

Amend the paragraph beginning at line 14 of page 36, as follows: 

-Figure 34 is a flow diagram of example implementation of the Client: :resourceIsUp 
function. This function is provided by a client to specify client specific processing to be 
performed when a resource comes up. In step 3401, this function sets a resource is up [a] flag for 
the client. The client also provides an analogous function for when a resource goes down.— 

Amend the paragraph beginning at line 23 of page 36, as follows: 

- Figures 35-39 are flow diagrams of functions of a resource manager for watching a 
resource. Figure 35 is a flow diagram of an example implementation of the ResourceUp function 
of the resource manager. The resource manager invokes this function whenever a resource at that 
node is detected as being up. The resource manager may know that a resource is up because it 
controlled the creation of the resource at startup, because it dynamically created the resource 
when requested by another resource, or because another resource created that resource and 
registered the created resource with the resource manager. This function is passed a pointer to 
the resource that is now up. In step 3501, if the bus is up, then the function notifies the bus 
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manager by invoking the attach function of the bus manager passing the identification of the 
resource that is now up a else the function returns. In step 3502, the function updates the local 
resource directory to indicate that the passed resource is up. The function then returns.-- 

Amend the paragraph beginning at line 1 1 of page 41, as follows: 

—Figure 45 is a flow diagram of an example implementation of the Directory: :monitorRes 
function. This function is implemented by the resource manager and is invoked by a client to 
start monitoring for the passed resource to go down. In step 4501, the function uses the passed 
resource to identify the server node (i.e., the node where the resource is located) for the resource. 
The function may use the query interface function of the resource to retrieve a pointer to an 
interface for identifying the server node. The function also updates the monitor resource table for 
the resource and client so that the client can be notified when the resource goes down and so that 
the server node can be re-notified if it goes down and comes up. In step 4502, if a connection has 
already been established with the server node as indicated by the client connection table, then the 
function continues at step 4508, else the function continues at step 4503. In step 4503, the 
function establishes a connection with the server node by invoking the connectClient function of 
the server node passing a pointer to an interface of the client node for receiving notifications and 
passing a client context for identifying this connection. The invocation returns a server context. 
In step 4504, if an error is detected when invoking the connectClient function, then the function 
continues at step 4505, else the function continues at step 4506. In step 4505, the function 
assumes that the [is] server node is down and performs the associated processing and then 
returns. In step 4506, the function updates the client connection table to indicate that a 
connection has now been established with server node with the client and server context. In step 
4507, the function signals to start sending a client is alive message periodically to the server 
node. The sending of the client is alive message may be considered to be one form of "leasing" a 
resource. In step 4508, the function invokes the monitor resource function of the server node 
passing the identification of the resource to be monitored. The function then returns.-- 

Amend the paragraph beginning at line 5 of page 46, as follows: 

—The tracking system also provides for watching the properties of a server resource by a 
client resource. A property of a resource corresponds to data related to the resource whose value 
can be set by that resource during execution of a function of the resource. That function can be 
invoked [involved] by another software component. The function may be specifically provided 
to set the value of the property (e.g., a set property function) or may set the value of the property 
as a side effect. In one embodiment, a property watching component of the resource tracking 
system allows client resources to register their interest in receiving notifications when a property 
of a server resource is set. The client resources also specify the behavior to be performed when 
the property is set. The property watching component provides a synchronous mechanism for 
notifying client resources when the property is set. This synchronous mechanism ensures that 
client resources who are registered to watch a property are notified of the setting of the property 



-27- 



DOCKET NO.: MSFT-0677/1 83 204.1 



PATENT 



before any client resources are notified of a subsequent setting of the property. The property 
watching component thus provides a mechanism for synchronizing processing among multiple 
client resources.— 

Delete the paragraph beginning on line 19 of page 48, as follows: 
-[[Add ManResIsDownBlock to Figures- 
Amend the paragraph beginning at line 1 of page 51, as follows: 

—Figure 61 is a flow diagram of an example implementation of a register watch function 
of a client resource. This function is passed the identification of the server resource, the name of 
the property to be watched, and identification of the client resource. In step 6101, if the client 
resource is already watching that property, then the function continues at step 6106, else the 
function continues at step 6102. In step 6102, the function creates a unique context for the client 
resource and property. In step 6103 [6102], the function invokes the watch property function of 
the server resource passing the name of the property and the context. In step 6104, the function 
creates a property client object for that property and adds that object to the client object list of the 
resource reference object for that resource. In step 6105, the function adds an entry to the 
context/property table. In step 6106, the function adds a property reference object to the list 
associated with the property client object and then returns.— 

Amend the paragraph beginning at line 24 of page 51, as follows: 

—The event system provides a mechanism for providing event notifications when events 
are generated by resources. An event is an asynchronous signal that is distributed to all client 
resources, also referred to as listeners, who have registered to listen for an event signal. In one 
embodiment, the event system neither guarantees that a listener will receive the events in the 
order they are generated nor guarantees that each listener will receive every event for which it is 
listening. Each event has an associated event type. A listener registers to listen for events of a 
certain event type. In one embodiment, the event types may be hierarchically organized. For 
example, one event type may be a timer event. The timer events may be further classified into 
catastrophic timer events, warning tuner events, and informational timer events, which are 
sub-events. An informational timer event may further be classified into start-up timer events and 
shut-down timer events. A listener may register to listen for events at any level in the event 
hierarchy. For example, a listener may register to listen for informational timer events. That 
listener would receive an event notification as for start-up tuner events and a shut-down timer 
events. A listener will receive event notifications for leaf events of the sub-tree corresponding 
[correspond] to the event [vent] type registered. A leaf event is an [in] event that is not further 
classified into sub-events. An event type may have its hierarchy embedded in its name. For 
example, the name of start-up timer event may be "/timer event/informational time event/start-up 
timer event."-- 
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Amend the paragraph beginning at line 16 of page 52, as follows: 

-Figure 63 is a block diagram illustrating components of the event system in one 
embodiment. A client 6301 registers to listen for events by sending a listen message along with 
an event type to the listener component 6303. The client receives from the listener component an 
event notify message along with event information when an event of that event type is generated. 
The client un-registers its interest in listening for events of a certain event type by sending a stop 
listening message along with the event type to the listener component. In one embodiment, each 
node has [as] a listener component through which is routed all event-related messages for all 
listeners on that node. The listener component may in turn route event-related messages to a 
listener bus manager 6305. The listener component notifies the listener bus manager to listen for 
all event types for which listeners on that node have registered. The listener component may 
send only the listener bus manager. There is one [One] listen message for each event type 
regardless of how many listeners at that node have registered for that event type. For example, if 
a listener component receives requests from six clients, the listener component sends only one 
listen message to the listener bus manager. The listener component maintains a listener table 
cache 6306 that contains a mapping from each event type for which a listen request has been 
registered and each client that has registered for that event type. When the listener component 
receives an event notification, it uses the listener table cache to notify each listener that has 
registered for that event type. In this way, the listener component reduces the event messages 
that are sent between that node and the node of the listener bus manager. When the listener 
component receives event notifications, it queues an event notifications for each of the listeners. 
The listener component uses a separate thread for providing the event notification to each 
listener. If a single thread were used to notify each listener, the event notifications could be 
delayed to some listeners as a result of a delay or problem in notifying another listener. The use 
of a separate thread for each listener ensures that the notification to one listener will not be 
delayed as a result of an event notification to another listener. The listener component may 
receive a bus state change message. If the bus goes down and then comes back up, the listener 
component can reregister with the listener bus manager to receive the events of the event types in 
its listener table cache. The listener component may also optimize its sending of listen requests * 
based on the event hierarchy. For example, if a listener registers to listen for a informational 
timer, the listener component will register that request with the listener bus manager. If another 
listener registers to listen for a start-up timer, then the listener component will not need to 
register that request with the listener bus manager. Since the listener component has already 
registered to receive a higher-level event type, it is already registered to receive all lower-level 
event types.-- 

Amend the paragraph beginning at line 25 of page 54, as follows: 

- There [the] are various components in the system that are responsible for the collecting, 
storage, and possible forwarding of log records. All forms of this component are modeled by the 
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HcsLogFacility class.— 

Amend the paragraph beginning at line 2 of page 55, as follows: 

—The HcsLogFacility class is an HcsResource derivation whose [who's] purpose is to 
provide storage and forwarding at various levels in the system. There are currently two 
implementations: the Local Log Facility, and the Central Log Facility. The HcsLogFacility 
interface is:~ 

Amend the paragraph beginning at line 20 of page 55, as follows: 

—An [A] Local Log Facility (LLF) instance (only one!) exists in every node in the system. 
The purpose of this HcsLogFacility implementation is to accept all log records from various 
HCS components on that node and to buffer them in a large circular on disk until they can be 
delivered to the Central Log Facility (CLF). The intent is that a node could survive for some 
time if the CLF were to be unavailable. One of the configuration parameters passed to each 
Local HcsLogFacility instance will be the resource name of the HcsLogFacility through which 
that instance is to forward its records. The current thinking is that this will be the name of the 
CLF,, but this is not an architectural requirement. In other words,, there could be intermediate 
levels of HcsLogFacilities placed in the system. In fact, an [on] LLF could be configured to 
forward its records to another LLF. After all an [a] HcsLogFacility is a HcsLogFacility. - 

Amend the paragraph beginning at line 9 of page 56, as follows: 

-So the question is: how do HCS components log their [there] information? To provide a 
standard and safe access to the HcsLogFacilities, there is a class family provided. The family is 
based at a class called HcsLogPort. This class implements the common behavior of all types of 
LogPorts and is functional on its own.— 

Amend the paragraph beginning at line 13 of page 56, as follows: 

—Derived from the HcsLogPort are the HcsResourceLogPort and HcsLogFacilityPort 
classes. The HcsResourceLogPort provides [provide]easy support for the resource developer 
while the HcsLogFacilityPort provides direct access to HcsLogFacilities. In general, the first is 
used by Resource derivations while the second would be used by resource servers and system 
components.- 

Amend the paragraph beginning at line 18 of page 59, as follows: 

— HcsResourceImp::putLogRecord implementation: keeps an [and]internal 
HcsLogFacilityPort instance which is used to forward records through. Before a record is 
actually forwarded, HcsResourcelmp checks to make sure an HcsLogFacility has been assigned 
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[assign] to its port. If this is not the case, an attempt is made to locate the local HcsLogFacility 
for that node via the HcsResrcBusIf::locateLocalResourceById method (new). In any case, the 
log record is written [to the ]via the resource instance's HcsLogFacilityPort.-- 

IN THE CLAIMS: 

Please amend claims 1 to 7 as follows: 

1 . (Amended) A system for managing software components in a distributed computing 
environment, the system comprising: 

a tracking system for tracking when a software component changes state [states] and for 
providing a state change notification [notifications] of a change [changes] in state of the tracked 
software component; and 

a property notification system for providing a property notification [notifications] to the 
software component [components] when a property of another software component is set= 
wherein [so that] software components of the system use services of both the tracking system and 
the property notification system. 

2. (Amended) The system of claim L further including: 

an event notification system for providing an event notification to the software 
component [components] when at least one of the software component and another [a] software 
component generates an event. 

3. (Amended) The system of claim 1 , further including: 

a logging system for logging records of activity of the software component [components]. 

4. (Amended) The system of claim 1 , further including: 

a directory component that receives a tracking reference and returns a corresponding 
behavioral reference. 



-31- 



DOCKET NO.: MSFT-0677/183204.1 



PATENT 



5. (Amended) A system for managing software components in a distributed computing 
environment, the system comprising: 

a tracking system for tracking when a software component changes state [states] and for 
providing a state change notification [notifications] of a change [changes] in state of the tracked 
software component; and 

an event notification system for providing an event notification to the software 
component [components] when another [a] software component generates an event , wherein [so 
that] software components of the system [component can] use the services of the tracking system 
and the event notification system. 

6. (Amended) The system of claim 5 , further including: 

a logging system for logging records of activity of the_software component [components]. 

7. (Amended) The system of claim 5 , further including: 

a directory component that receives a tracking reference and returns a corresponding 
behavioral reference. 

Please add new claims 8 to 39, as follows: 

—8. In a system for a distributed computing environment, wherein the system includes a 
communications bus, a bus manager having at least one bus management component, at least one 
server node and at least one client node, wherein said at least one server node, said at least one 
client node and said at least one bus management component are interconnected via said 
communications bus, and wherein each of said at least one client node includes at least one client 
resource for requesting notification when at least one of an event is generated, a server resource 
of said at least one server node changes state or a server resource of said at least one server node 
changes a property, a method for managing resources of the system, comprising: 
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tracking when a software component changes state and providing a state change 
notification of a change in state of the tracked software component; and 

providing a property notification to the software component when a property of at least 
one of the software component and another software component is set. 

9. A method according to claim 8, further comprising: 

providing an event notification to the software component when at least one of the 
software component and another software component generates an event. 

10. A method according to claim 8, wherein said tracking includes: 

receiving by the system a request from the client to track a state of the object; 

watching the state of the object to detect when the object enters the up state and when the 
object enters the up state, first performing at least one behavior that is specified by the client to 
be performed when the object enters the up state and when the object is in the up state, 
monitoring the state of the object by the system to detect when the object enters the down state; 
and 

monitoring the state of the object to detect when the object enters the down state, and 
when the object enters the down state, second performing at least one behavior that is specified 
by the client to be performed when the object enters the down state. 

11. A method according to claim 8, wherein said providing a property notification includes: 
first registering by the client resource to track a server resource; 

after the server resource enters the up state, second registering by the client resource to 
watch a property of the server resource; and 

after the property of the server resource is set, invoking by the server resource a property 
set function of the client resource. 

12. A method according to claim 9, wherein said providing an event notification includes: 
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registering by a client resource an interest in an event type; 

upon the occurrence of an event classified with said event type, providing an 
asynchronous event signal that is distributed to all client resources that have registered to listen 
for the signal. 

13. A method according to claim 12, wherein each event has an associated event type 
whereby event types are aggregated types. 

14. A method according to claim 13, wherein each event has an associated event type 
whereby event types are hierarchically organized. 

15. A method according to claim 14, wherein registering by a client resource for a particular 
event type includes registering the client resource for all event types falling with the hierarchical 
classification for the particular event type. 

16. A method according to claim 14, wherein event types include a timer event type. 

17. A method according to claim 16, wherein a timer event type is one of a catastrophic 
timer event, a warning timer event and an informational timer event. 

18. A method according to claim 17, wherein an informational timer event is one of a 
start-up timer event and a shut-down timer event. 

19. A method according to claim 14, wherein the hierarchy of an event type embedded in the 
identification of the event type. 

20. A method according to claim 9, wherein said providing an event notification includes: 
registering by a client resource of a client node with a listener component an interest in 
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listening for an event, wherein said registering includes invoking a listen message and specifying 
an event type to the listener component; and 

receiving by the client resource from the listener component an event notify message 
along with event information when an event of that event type is generated. 

21 . A method according to claim 20, wherein said providing an event notification further 
includes: 

un-registering by the client resource the interest in listening for the event, wherein said 
un-registering includes invoking a stop listening message along and specifying the event type to 
the listener component. 

22. A method according to claim 21, wherein each client node has a listener component 
through which is routed all event related messages for all client resources registered to listen for 
events on the node. 

23. A method according to claim 22, wherein a listener component of a client node routes 
event-related messages to a listener bus management component whereby the listener component 
notifies the listener bus management component to listen for all event types for which client 
resources are registered to listen for events on the client node. 

24. A method according to claim 23, wherein each listener component includes a listener 
table cache that contains a mapping from each event type for which a listen request has been 
registered and for each client that has registered for the event type, such that when the listener 
component receives an event notification, the listener component accesses the listener table cache 
to notify each client resource registered to listen for the event type. 

25. A method according to claim 23, wherein the listener bus management component 
includes a listener table that contains a mapping from each event type to the registering client 
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nodes such that when the listener bus management component receives an event posting, the 
listener bus management component notifies each node that has registered to listen for events of 
the event type and for events of any event type that is aggregated within the event type. 

26. A method according to claim 25, wherein the listener bus management component 
notifies each node that has registered to listen for events of the event type and for events of any 
event type that is a hierarchical parent of the event type. 

27. A method according to claim 8, further including: 

logging activity of the software component in at least one log record. 

28. A method according to claim 27, wherein each of the at least one log record comprises at 
least one of: type information, time information, creator information and text information. 

29. A method according to claim 27, wherein said logging includes logging at a local log 
facility and logging at a central log facility. 

30. A method according to claim 29, wherein each client node includes an instance of a local 
log facility which receives all log records from various software components on the client node 
buffers the log records until they are transmitted to the central log facility. 

31. A method according to claim 30, wherein a local log facility is configured to forward its 
recordsto another local log facility instead of the central log facility. 

32. A method according to claim 29, wherein there is only one instance of the central log 
facility for the whole system which accepts all log records from all components within the system 
and whereby the central log facility provides for the final storage of logging information. 
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33. A method according to claim 29, wherein the central log facility provides long term, off 
line, archival of the entire system. 



34. A method according to claim 29, wherein the central log facility provide for on-line 
viewing of a desired portion of the log records. 

35. A method according to claim 27, wherein said logging is capable of being disabled. 

36. A method according to claim 8, wherein a server node of said at least one server node is 
also a client node of said at least one client node. 

37. A computer readable medium comprising computer executable instructions for 
performing the method of claim 8. 

38. A modulated data signal carrying computer executable instructions for performing the 
method of claim 8. 

39. A computing device comprising means for performing the method of claim 8.-- 
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